Single select (dropdown)
Allows users to select one option from a predefined list
Examples
Usage
Research shows some users find single selects clunky and hard to use. It’s generally best to consider other input options first. Single selects are often overused in Turas forms. Before choosing a component that allows user to make a selection, think about whether a different component would be more user-friendly.
Do:
- match the select width to the length of the longest option rather than stretching it to other fields' widths
- consider alternative form components like radio buttons for better usability
- use a text box with autocomplete if users likely know what they're searching for
- use a single select for 5 to 15 options
- include a clear, descriptive label beside the single select using the <label> tag
- use short, descriptive option labels
- provide an instructive placeholder inside the single select, e.g. 'Select NHS Board' rather than '--Please select--'
- sort options from the user's perspective, usually alphabetically or numerically, unless another pattern suits better
- support keyboard input to select visible options or jump to options starting with a typed letter
- use single select when the default option is recommended
- group related options with a distinct hierarchy using the <optgroup> tag for easier scanning but don't rely on it for critical info as screen readers may ignore it
Avoid:
- using a single select for lists with more than 15 options, instead reduce the number of options or use a text input, autocomplete, or a multi select
- using a single select with four or fewer options, instead use stacked radio buttons instead
- choosing a single select for data that is highly familiar to users, such as a date of birth
- adding functionality to allow the user to select multiple options
- starting with a default selection unless at least 80-90% of users are likely to select that value
- when you want to emphasise options that have no clear default or recommended value, or when options are unfamiliar and require careful reading
- when the user needs to view a clear comparison of their options
- using select for navigation unless a form submit button is positioned next to it
References
Gov.UK Design System
Select
Neilson Norman Group
Dropdowns: Design Guidelines
Parameters for turas-select-list
- asp-for - binds the select list to a model property
- asp-items - specifies the items to be displayed in the select list
- guidance-text - provides additional guidance for the user
- live-search - enables a live search feature within the select list
- field-column-widths - sets the column width for the select list
- additional-classes - allows for additional CSS classes to be applied
- hide-validation-message - suppresses validation messages for the select list
- asp-is-disabled - disables the select list, making it unselectable
- hide-label - hides the label for the select list
Are you sure you want to close without saving?
Any information you have entered will be lost!
Testing
Check that the single select:
- can be navigated with keyboard only
- shows a visible focus state on the control and selected options
- expanded/collapsed state of the dropdown is communicated correctly to screen readers
- announces the label, role, available options and selected options correctly with screen readers
- hint text or instructions are read out by screen readers
- check error messages are announced by screen readers and associated with the multi select
- does not trigger unexpected changes while an option is selected
- remains usable at 400% zoom and supports reflow without horizontal scrolling
- makes it clear when selecting an option will reveal additional fields
- make sure opening the option list does not create a keyboard trap
Developer considerations
When using the single select component in your form:
- always use the native <select> element where possible
- always provide a visible label using <label for=""> and an ID
- include a default empty option where appropriate (for example, “Select a country”)
- make sure the single select has a programmatic name (via label or aria-labelledby)
- use aria-describedby to associate hint text and error messages with the single select
- avoid pre-selecting options unless there is a clear user benefit and it does not create a risk of unintended choices
- make sure custom select components maintain native select behaviour
- write error messages that explain what went wrong and how to fix it
- make sure a visible focus state that meets contrast requirements
- make sure the component remains usable when text is resized and content reflows
- make sure sufficient touch target size and spacing, with a target size of at least 24 × 24 CSS pixels
Required fields
If your form contains fields that users must complete:
- clearly indicate when the single select is required by using a visual indicator such as an asterisk
- do not rely on the visual indicator alone (for example, an asterisk) to communicate that a field is required and include the help text “Required fields are marked with an asterisk *” at the top of every page of the form
- make sure the required state of the single select is programmatically available to assistive technologies using aria-required="true"
Conditional behaviour
If your single select reveals additional content based on a user's selection:
- only reveal content when it is logically dependent on the selection
- do not automatically move focus when content is revealed
- place revealed content directly after the single select that controls it in the DOM
- hide the content from all users, including assistive technology users, until it is needed
- make sure hidden fields are not focusable
- when revealed, make sure the content is reachable in the natural tab order
- consider adding hint text to explain that additional fields may appear
- use the Turas conditional reveal pattern so the new content is available to screen readers